UPDATES.TXT This file contains a description of modifications made to CDB For Windows since its inception. Version 0.90 (released 04/22/91) ============ - Initial release. Version 0.91 (released 05/06/91) ============ - The documentation has been enhanced. - The sample source files have been modified to support the Zortech C/C++ compiler. Zortech C/C++ does not have a memory.h header file. - Internal key pages were modified to be non write-through. Before this modification, all CDB database calls would flush modified pages to disk before returning to the calling function. This change will greatly enhance the speed at which database records can be added, modified and deleted. To ensure that data is written to disk, call the DbFlush function. This function has been modified to write all 'dirty' pages to disk. - The DBSERVER.EXE 'cdb' function, a common entry point for all cdb calls, has been modified to be ANSI C compatible. This function takes a variable number of arguments. The argument list is now being retrieved via the 'va_start', 'va_arg' ANSI C function calls. Version 0.92 (released 05/16/91) ============ - The documentation has been enhanced. - The dbtalk library source files and the sample program source files have been modified to support the Borland C++ v2.0 compiler. The dbtalk libraries included have been compiled with Microsoft C but are compatible with Borland & Zortech C++. Version 1.00 (released 06/26/91) ============ - The documentation has been enhanced. - Converted DBTALK library to a DLL. - Changed DbOpen database HANDLE parameter (hDb) to LPHANDLE. See documentation. - Added DbGetNbrClients function call. This function returns the number of applications that have opened a particular database. - Added file locking capabilities. More than one application can access the same database concurrently. New functions added include; DbFileLock, DbFileUnlock, and DbFileGetLockStatus. This feature does not provide LAN access capabilities. Multiple applications running under Windows on a single CPU can access a database concurrently. - Modified the database server (DBSERVER.EXE) to be displayed as an icon. - Fixed problem with DDLP.EXE. DDLP would not accept a type double declared as an array. Example: double test[8]; Version 1.01 (released 9/16/91) ============ - Created a WINHELP compatible CDBW help file. This replaces CDBW.WRI. - Modified DbOpen function. Added a hide parameter. This parameter is set to TRUE if you wish to hide the DbServer icon. See the documentation for more info. - Modified the WEP() DBTALK.DLL function to close all open DBSERVER's if the DLL is being removed from memory. - Modified DbRecordDelete function to check for 'records owning' or 'records owned by' the record about to be deleted. If either of the forementioned exist, an error is returned. E_HASOWNER and E_HASMEMBER respectively. - Modified DBSERVER.C to handle the WM_CLOSE message. If a WM_CLOSE message is received and an application has the database open (most likely a UAE occured and the database was left open), the database is closed. - Modified DDLP (Data Defintion Language Parser) to create Visual Basic compatible header files. Use the -vb flag. It will create a .TXT file instead of a .H file when this flag is used. Version 1.02 (released 10/18/91) ============ - Fixed bug with DbRecordGetCurrent and XDbRecordGetCurrent. A UAE would occur occasionally during these function calls because of a bad parameter passed. - Fixed bug with DbRecordGetByKey and XDbRecordGetByKey. When an E_NEXTGUESS value was returned, the target structure passed did not contain the 'Next Guess' record. Version 1.03 (released 11/04/91) ============ - Fixed bug with DbFlush function call. The DbFlush function closes all open files and then proceeds to reopen them. The path used for reopening was invalid. This problem would mostly occur with PREFIX's (in the DDL file) declared with greater than 3 characters. - Fixed bug in internal page flushing. When a handle in the LRU table was closed, the associated pages with this handle were not being flushed to disk. This problem would only be visible if you had a large number of record types declared in the DDL.